In one-to-many data communication, the same information is to be sent to many different data processing stations. This situation is commonly known as “broadcast” or “multicast”. Broadcasted messages are typically directed to all network nodes, while multicasted messages are directed to a subset of nodes on the communications network the message is intended for. A number of networks (e.g., token ring, Ethernet, radio, microwave and satellite networks) possess broadcast or multicast capabilities. However, the multicasted or broadcasted message can still be missed or incorrectly received by one or more network nodes (e.g., the message may be distorted due to electrical interference, loose connections, faulty hardware, slow or busy receiving data processing stations, or other reasons).
Multicast transmissions are becoming increasingly common. In contrast to standard Internet Protocol (IP) point to point transmissions (unicast), IP multicast enables the simultaneous transmission of information to a group of recipients from a single source. In this approach, a multicast server transmits data over one or more multicast channels which one or more client receivers join or subscribe to. In this model, the server only sends out one copy of the data irrespective of the number of client recipients listening to the appropriate multicast channel or channels. In IP multicast, the server does not even need to know who the recipients are or the number of recipients in a particular multicast group.
IP multicast enables real-time communications over wide area IP networks and typical transmissions include video and audio conferencing, live multimedia training, university lectures, and transmission of live television and radio programmes, for example. IP multicast also enables more persistent data to be transmitted, including for instance, media session descriptions comprising session-oriented and user-oriented data.
A multicast media session usually consists of one or more individual media streams typically carrying video, audio, whiteboard or raw data. Some sessions are persistent, but the majority exist for a specific period of time, although need not be continuous. Multicast-based transmissions differ from unicast IP transmissions in that any user knowing about the transmission can join the session (unless the transmission is encrypted) and to receive a transmission, a user only needs to know the appropriate transmission group address and timing information for the session.
The Multicast messaging protocol is unreliable insofar as the unidirectional messaging protocol does not provide a mechanism for confirming or insuring delivery of the message packets. In this regard, the various individual data packets are communicated in the same fashion as a datagram over an IP network. For many applications, an occasional lost packet is acceptable, and a multicast messaging protocol is a viable mechanism for communicating data from a single source to a plurality of receiving nodes.
In some systems, however, reliable delivery of the data is important. Consider, for example, an audio or a video broadcast. Losing occasional packets of the data at various nodes, from time to time, results in content of the audio or video broadcast being missed. Such missed content is often undesirable. In some such systems, where reliable transmissions are desired, a layer is provided over the IP layer that ensures successful delivery and receipt of the various packets of data, by providing for acknowledgments from the receiving nodes. In such systems, a packet of data may be sent via multicast protocol to one hundred (for example) different nodes or machines. Each node may respond with an acknowledgement to the sending node to confirm receipt of the transmitted packet. If, for example, four of the one hundred nodes do not successfully acknowledge the packet, then the sending node may be configured to individually retransmit the packet to each of those four machines. Once receipt of the transmitted packet is confirmed by all machines that are a part of the session (or group of receiving nodes), the transmitting node may proceed to the transmission of the next packet of data.
Such an approach sacrifices throughput in favor of the integrity that all data transmitted is received at all nodes. Such a solution is acceptable in systems where real time participation is not required. For example, in an application in which users are viewing or listening to a video or audio broadcast, it is often irrelevant if the viewing takes place with a time lag (e.g., twenty seconds after the broadcast). In such systems, each of the receiving nodes may have an appropriate buffer for buffering the data received from the sending node, whereby enough data is buffered so that the replay of the audio or video broadcast appears continuous to the user, albeit in a relatively significant time delay from the time it was broadcast from the transmitting computer.
In other applications, such a solution is not acceptable. Consider, for example, high-end systems that are configured for rendering three-dimensional computer graphics. Such systems involve computationally-intensive processes, whereby three-dimensional computer graphics are rendered by using a pool or group of computers, which share the processing responsibilities. In such a system, one computer may be configured to execute at least one application program and communicate graphics data to other computers for processing and rendering. In this regard, a collection of computers may be configured to cooperatively render a graphics image and may receive the data to be rendered from the computer executing the application program. The rendered image, then, may be displayed on a single display for viewing by a user who is interacting with the application program. In such a system, it is important that: (1) all graphics data transmitted by the computer executing the application program be successfully received at each of the various render nodes; and (2) that the communication occur in substantially real-time, so that there is no appreciable delay between the interactions between the user and the application program as the resulting display is presented to the user. Clearly, such systems involve competing interests, in view of the forgoing discussion.
In this regard, if all data is not successfully received by the various render nodes, then portions of the graphics image may either be missing from the display, or the display of the graphics image may appear choppy, or the image may appear degraded. Likewise, if the visual display is displayed to a user with an appreciable time lag, then interaction between the user and the application is frustrated.